1. Field of the Invention
This invention relates to computer systems and, more particularly, to handling memory management errors within computer systems.
2. Description of the Related Art
Memory management has long been known as a source of errors or “bugs” in computer applications. Often applications, e.g., those applications written at least partly using programming languages such as C and C++ that allow programmers to manage memory, are introduced into production environments even though they may contain memory management bugs. Even programs that may be considered relatively bug-free, e.g., as a result of thorough testing prior to release, may rely on third-party libraries that may contain memory management bugs. As a result, the executable code of a production application may often result in various types of memory management errors such as memory leaks, premature frees, duplicate frees, memory smashes etc.
Various techniques have been developed to identify such memory management errors, e.g., by instrumenting the application code to track object creations and deletions. Several such techniques support the elimination of certain types of memory management errors by implementing global error correction or prevention. For example, in one such global technique, all explicit programmer-initiated memory de-allocation functions (e.g., “free( )”) may be eliminated from the application via code substitution or code modification, and a conservative garbage collection mechanism may instead be used to release memory. In another such global scheme, memory smashes (where a program modifies memory beyond the end of an allocated object, thus potentially modifying neighboring objects or data structures) may be largely or completely avoided by extending the size of each allocated object by additional bytes.
However, many of these global techniques may be accompanied by negative side effects. For example, a global replacement of programmer-initiated memory de-allocation by conservative garbage collection may result in a substantial increase in both execution time (e.g., because of the extra processing required for the garbage collection) and memory used (e.g., because the aggregate amount of memory used by the application may grow relatively large between successive garbage collection events). Adding extra bytes to each allocated object to avoid memory smashes may also lead to excessive use of memory. The frequency of occurrence of memory management bugs within a program relative to the frequency of occurrence of “correct” (i.e., error-free) memory operations may often be relatively low, so that the overhead of global memory error handling schemes may not always be justifiable in some cases. In fact, in practice, the overhead of the global techniques has sometimes been found to be so high that administrators have deliberately disabled global memory error handling mechanisms; that is, administrators have sometimes been willing to accept the risks of memory management errors in preference to the overhead of global memory error handling. A more flexible approach towards memory error handling may provide application administrators and application users with a better tradeoff between the risk of memory management errors and the overhead of error prevention or correction.